A variety of real-world challenges arise in today's voice authentication technology accompanied by an increasing business demand for security in telephone applications. While most of the current challenges are directly or indirectly related to accuracy, robustness and computational efficiency, future field deployments with an ever growing number of biometric (in particular voice-enabled) user accounts will bring new sets of practical issues with them. The dynamically evolving area of biometric authentication, particularly speaker recognition, promises one such challenge: legacy issues in biometric (e.g. voiceprint, fingerprint, etc. model) maintenance. It is reasonable to expect that the average life span of a user account is likely to last longer than an innovation cycle of the underlying authentication technology. In other words, for a voice-enabled (or other biometric) account including the user's model representation, the particular implemented algorithm that created the model may change one or several times during the overall period of using the account.
Because the parametric structure of the user models is dictated by the underlying algorithms used to produce them, significant legacy issues (i.e., incompatibilities) can be introduced into existing large-scale databases of users. Consequently, algorithmic changes rendering existing accounts obsolete put in front of infrastructure providers new problems and decisions. For instance, assume that a service provider maintains several hundreds of thousands of voice-enabled accounts including users voiceprint models in their database. These models have a close relationship to data and algorithmic components inherent to the system. With a new generation of updated (improved) components, the provider is faced with the question of how to keep the existing accounts usable (i.e., voice-enabled). Among the few possibilities for addressing this problem are: 1) have users actively re-enroll into the new system, 2) automatically re-enroll users from a stored original waveform, 3) keep multiple system versions on line to support obsolete as well as new accounts, or 4) automatically convert obsolete models to the new configuration. Obviously, each solution builds on different assumptions (e.g. on the existence of an original waveform in case of voiceprints), has different consequences (e.g. increased complexity due to multiple system versions), and degrees of practicability (e.g. having users call to re-enroll, which may be unacceptable).
In view of the foregoing, a need has been recognized in connection with maintaining the functionality of users' accounts in the face of ever-changing components.